Add tuning parameters for the similarity profiles of the surface layer#4
Add tuning parameters for the similarity profiles of the surface layer#4wlanghans wants to merge 9 commits intowolfgang/rebase_sofar-071124_on_mainfrom
Conversation
…, to tune the surface layer parameterization
…of the SL layer over oceans
StevePny
left a comment
There was a problem hiding this comment.
Minor comments. As long as there are no breaking changes, I think this can be merged as soon as it's tested.
|
|
||
| call monin_obukhov_similarity | ||
| & (z1(i), snwdph(i), thv1, wind(i), z0max, ztmax, tvs, | ||
| & (islimsk(i), z1(i), snwdph(i), thv1, wind(i), z0max, |
There was a problem hiding this comment.
Since you're adding a new argument, I'd feel better in terms of backwards compatibility if it is put at the end of the argument list and made an optional argument (i.e. uses a default value if it is not provided).
There was a problem hiding this comment.
Backwards compatibility means that old results are achievable after changing code. This subroutine, and the whole PR, is setup to be backward compatible with the logical flag tune_ocean_surface_layer per default set to false; this makes sure results are unchanged per default. Even if the flag is true, the alphas are set to the default value unless changed through the config. For the order of arguments, it is Fortran standard to have inputs come first and outputs after that. All calls to this subroutine need these new arguments to support this tuning feature. In that sense, they are not optional.
Please let me know if that does not answer your comment appropriately or you still have concerns.
There was a problem hiding this comment.
That makes sense to me @wlanghans, switching the order would be more confusing since I (and any Fortran user) should expect inputs to come before output arguments. As long as the default works and doesn't change results (i.e. is backward compatible), I think this works well.
…d tuning by using the modified similarity functions to define phim and phih in satmedmfvdiff, satmedmfvdiffq, and moninedmf; a subroutine to compute the similarity functions has been created to avoid redundancy
miguelsolanocordoba
left a comment
There was a problem hiding this comment.
This looks good to me, and would be good to merge after testing that that default behavior (tune_ocean_surface_layer=False) does indeed return identical results (i.e. that it is backward compatible).
I like the idea of tuning stable/unstable regimes separately. There is enough uncertainty in these "universal" tuning parameters (alpha) to justify their tuning around these ranges.

Description
This PR adds two tuning parameters, one to tune the surface layer parameterization during stable, and one to tune it during unstable conditions. The default values correspond to the original formulation. These two parameters have an effect only over water surfaces when the land/sea/ice mask takes a value of 0 and when tune_ocean_surface_layer=True. Otherwise, the standard parameterization is used and the tuning parameters have no effect.
For consistency, these same modified profiles are also used in the PBL schemes satmedmfvdiff, satmedmfvdiffq, and moninedmf.
The design of these tuning coefficient is as follows:
References:
-Dyer, 1974: A review of flux-profile relations. Bound. Layer Meteor., 7, 363-372.
-Hicks, 1976: Wind profile relationships from the Wangara experiment. QJRMS, 102, 535-551.
-Hogstrom, 1988: Non-dimensional wind and temperature profiles in the atmospheric surface layer: A re-evaluation. Boundary-Layer Meteorol., 42, 55-78.
-Long, 1986: An economical and compatible scheme for parameterizing the stable surface layer in the medium range forecast model. Office note 321, NOAA.
-Long, 1990: Derivation and suggested method of the application of simplified relations for the surface fluxes in the medium-range forecast model: Unstable case. Office note 356, NOAA.
How Has This Been Tested?
No.
Checklist:
Please check all whether they apply or not